\documentclass{article}

\title{dDist Aflevering G2}

\author{The Shadow Dread Lord Master-Gods\\of the\\Dark Evil Dead Doom Legion\\ \\Jeppe Hansen 20061245\\Steffen Jensen 20061335\\Asger Feldthaus 20061089}

\newenvironment{code}{\begin{quote}\ttfamily}{\end{quote}}

\newcommand{\uri}[1]{\texttt{#1}}
\newcommand{\headerfield}[1]{\texttt{#1}}

\setlength{\parskip}{6 pt}

\begin{document}

\maketitle

\section{Subset of HTTP/1.0}
\textit{Argue for the selection of the chosen subset of HTTP/1.0}

In order to have a request response pattern working we have implemented a server that supporte GET requests. The server should be able to return a string or a file depending on how the evaluation of the request went.
If a file is requested, the server shold look for it in the wwwhome folder and return it. If a file is not found we would like to return a error string (this could in principle also be a file, but for now it is simply a string telling what went wrong in terms of a error code)
Thus the server will look for a GET header, and a path where to find a requested file.

If the socket connection to the client is disrupted doing a response (fx. by the client) a exception is thrown, and catched by the server.

A request for a picture like this:
\begin{verbatim}
GET /orly.png HTTP/1.1
\end{verbatim}
\\
Triggers a response similar to this:
\begin{verbatim}
HTTP/1.0 200 OK
Content-Length: 57756
Date: fr, 08 feb 2008 13:00:06 CET
Content-Type: image/png
Server: DOOM WebServer Alpha
\end{verbatim}

All that is really needed for making a simple request response work is the headers shown above. 
The server only look at the clients request line. It only considers GET requests and don't care about the clients HTTP version. The HTTP version answer from the server is always HTTP/1.0. This is done by a regular expressin that is defined in the isValidRequest method of the HttpRequest class.


\section{Design overview}
\textit{Provide an overview of your design and implementation and in particular how it relates to the HTTP/1.0 specification}

The HttpServer class uses a socket to recieve and send informations from the client. The socket have a input stream and a output stream. We use a buffered reader to read the input stream from the client and a BufferedOutputStream to return the output to the client. The input from the client is parsed, and the relevant informations are stored in a container class called HttpRequest (this class also contains the parsing method). The response is setup in our HttpResponseFactoryImpl class. The method makes sure that a error response is returned if a unsupported request was made, else a correct response is returned. 
If a supported response is recieved, the response body is to be obtained from a file specified by the location in the requests first line. If this file is not found, a standard response is made (404 not found).
We have divided the response body into two. One that is able to return a string and one that is able to return a file.
The file requested is printed directly to the output stream from the FileResponseBody class.

The headers that is returned to the client is: Server, Content-Type and Content-Length. If a file is returned, we also add a date header.
It is the isValidRequest method of the HttpRequest class that validates the clients request using a regular expression. This can be done since regular expressions are strong enough to express the features that we have implemented.

A status message is printed in the terminal output when ever a request is made to the web server. If a request is disruptet by the client or multiple client requests happens in the same time, the server will report a error in the terminal output. 

\section{Implementations on top of the server}
\textit{Discuss to which extent RPC, message-oriented communication, stream-oriented communication and multicast can be implemented on top of your server.}

\subsection{RPC}
Since the HTTP protocol it selv is a RPC, is is easy to implement a RPC on the server. The client can easy send some informations telling the server which "methods" to run and som arguments (in HTTP the called method opens a file, and the argument tells the server wich file to open). The server response can easy return the result of the calculation to the client.

\subsection{Message-oritented communication}

Actually TCP protocol is based on message oriented commuication, so actually the server already implements is it indirectly.
The Message Parsing Interface have a primitive called MPI\_sendrecv that sends a request to a reciever and blocks until a response is recieved, this basically is a RPC call. The operation MPI\_recv is used to specify that the client is waiting for a message, it blocks the client until a message is recieved. This also reminds of the HTTP protocol. But on the other hand the MPI altso supports methods that is not possible to do in the resonse request pattern described by the HTTP protocol. The MPI\_isend passes a reference to a outgoing message and continues. This behaviour is not supported by the HTTP protocol, since a request can only be followed by a response (or a time out).

The message oriented communication uses a stack to save requests until resourses are available to return an answer.

\subsection{Stream-oriented communication}
The underlying PCT protocol for our server only ensures that the data being send arrives in the correct order, but not at a certain time.
When a client is sending a request, the request is being streamed to the server, who listens until the whole request is received. The response is also send to the client by stream, but there is no garanty for the time when the package arrives. Since the HTTP protocol gives no garanty of the arrival time of the data, it is not possible to build a stream oriented communication protocol on top of our server.


\subsection{mulitcast}

The mulitcast is possible if we use multiple threads in the server. Since the server then will be able to handle multiple requests from clients and process response in parallel. How ever if we look at a application-level mulitcast, the server should be able to forward incomming requests to other nodes in the network. Nor will the gossip based data dissemination be possible to implement, since this also require the server to act as both client and server. (It would be possible to implement we disregard the request response pattern).


\end{document}